System and method for automated chat testing

ABSTRACT

A system for flexible and scalable automated chat-based contact center testing, comprising a test case management platform, “chat cruncher”, contact center manager, chat classifier, and desktop automation engine, and method for using such a system for automated testing of a contact center&#39;s chat-based interactions environment and reporting of test results.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of Ser. No. 14/854,003 titled,“SYSTEM AND METHOD FOR AUTOMATED CHAT TESTING” and filed on Sep. 14,2015 which is a continuation of U.S. patent application Ser. No.14/140,449, titled “SYSTEM AND METHOD FOR AUTOMATED CHAT TESTING”, filedon Dec. 24, 2013, now issued as U.S. Pat. No. 9,137,183 on Sep. 15,2015, which is a continuation of abandoned U.S. patent application Ser.No. 13/936,147, titled “SYSTEM AND METHOD FOR AUTOMATED CHAT TESTING”,filed on Jul. 6, 2013, which is a continuation-in-part of U.S. patentapplication Ser. No. 12/644,343, titled “INTEGRATED TESTING PLATFORM FORCONTACT CENTRES”, filed on Dec. 22, 2009, now issued as U.S. Pat. No.8,625,772 on Jan. 7, 2014. This application is also a continuation ofSer. No. 14/854,003 titled, “SYSTEM AND METHOD FOR AUTOMATED CHATTESTING” and filed on Sep. 14, 2015 which is a continuation of U.S.patent application Ser. No. 14/140,449, now issued as U.S. Pat. No.9,137,183 on Sep. 15, 2015, which is a continuation-in-part of abandonedU.S. patent application Ser. No. 13/567,089, titled “SYSTEM AND METHODFOR AUTOMATED ADAPTATION AND IMPROVEMENT OF SPEAKER AUTHENTICATION IN AVOICE BIOMETRIC SYSTEM ENVIRONMENT”, filed on Aug. 6, 2012, thespecifications of each of which are hereby incorporated by reference intheir entirety.

BACKGROUND OF THE INVENTION

Field of the Invention

The invention relates to the field of contact center operations, andmore particularly to the field of automated testing of chat-based clientinteraction software systems.

Discussion of the State of the Art

In the field of contact center operations, traditionally communicationbetween agents and customers is performed via voice-based systems suchas traditional telephony or voice over Internet protocol (VoIP) systems.However, more centers are beginning to accommodate additional,text-based communications such as Internet-based chat software commonlyfound in the art, to better serve customers who may not have access toor desire to utilize a voice connection. A common example of this wouldbe a customer browsing through an online catalog on a company's website.In such a scenario, a customer might have a question about a product,and both customer and company may benefit from the inclusion of aconvenient chat interface within a webpage, allowing customers tocommunicate directly with agents while still browsing the online catalogand from the convenience of their computer. This allows more convenientand speedy communications, without the need to navigate atelephony-based interactive voice interactive voice recognition (IVR)system to reach an agent or waiting in long queues for an agent tobecome available. It also allows more flexible communications, such as acustomer who may be viewing an online catalog from an Internet café orsimilar public location, where they may not have access to a telephoneor may not desire for their conversations to be overheard by others.

In accordance with this shift in contact center methodology, it will beappreciated that there exists a need to test and evaluate chat-basedsystems to ensure reliable contact center operation and resolve issuesthat might impact customer interactions, such as frozen chat sessions ordelay in text transmission. It will be appreciated that such testingsystems should also accommodate a variety of endpoints, such as chatinterfaces embedded in webpages, dedicated chat software to be run on apersonal computer or mobile chat applications, without affecting thereliability of test results and without requiring human interaction ormodification.

There exist in the art testing methods for voice communications, but itwill be appreciated that such methods may not translate well totext-based systems. Furthermore, while there are chat testing systemsimplemented in the art currently, such systems require the interactionof a testing agent to operate, which introduces new problems such asadditional expense for the time and labor involved in testing, humanerror factor which may influence reliability of testing protocols, andvarious inconsistencies associated with human operation.

What is needed is a flexible and scalable automated testing solution forchat-based communications, which may operate in parallel with aproduction environment without impacting ongoing customer interactionsand which may accommodate a variety of endpoints and infrastructureimplementations without negatively impacting testing reliability.

SUMMARY OF THE INVENTION

Accordingly, the inventor has conceived and reduced to practice, in apreferred embodiment of the invention, a method for automated chattesting which does not rely on specific chat software or endpoints andwhich is scalable to accommodate various implementation architectures,and a preferred system for implementation of such a method.

According to a preferred embodiment of the invention, a system forhandling automated chat testing for contact centers, comprising a testcase management (TCM) platform, “chat cruncher”, contact center manager(CCM), chat classifier, and desktop automation engine (DAE), isdisclosed. According to the embodiment, a TCM platform may present aweb-based, graphical user interface for creating and managing test casesand viewing results reports, as illustrated in detail in FIG. 6 and FIG.7. Such functionality may allow users to input additional testprotocols, view results of prior tests, view tests as they are being runfor realtime analysis, and manipulate test result reports (such as, forexample, selecting specific reports and exporting them to a database orother storage medium for backup purposes). A “chat cruncher”, accordingto the embodiment, may handle the loading and execution of test cases,including (but not limited to) such functions as generating simulatedcustomer traffic and testing various chat endpoints for customerexperience (such as, for example, embedded chat interfaces in webpages)and handling the automation of load testing by varying the amount oftraffic generated. A CCM system may simulate agent activity and performcontact center functions with regard to simulated customer traffic froma chat cruncher, and may replicate actual agent activities by directlymanipulating a chat server utilized by a contact center, thereby alsoincorporating testing of existing center architecture such as chatserver, CTI server, or other internal components. It will be appreciatedthat such implementation does not rely on any particular existingcomponents or arrangements, thus facilitating scalability to a varietyof contact center infrastructures. A chat classifier may be implementedaccording to the embodiment, to classify chat interactions according totheir nature as either simulated interactions being run by the testingsystem, or actual customer-agent interactions. In this manner, a chatclassifier may be used to enforce boundaries between the testingenvironment and production environment within a contact center, allowingtests to be run simultaneously without impacting center performance andcustomer experience. A DAE system may be used according to theembodiment, to directly manipulate an agent desktop environment ratherthan directly interacting with a chat server, adding the functionalityof testing the agent experience. Accordingly, a single exemplary testcase might perform testing of internal contact center systems such asCTI server or chat server as described above, agent desktop software,inbound traffic management and load handling, as well as customerexperience via a variety of chat interaction endpoints and overallrouting efficiency of all performed requests, and then store test caseresults data for viewing and analysis. It will be appreciated by onehaving skill in the art that the described preferred arrangement isexemplary and alternate arrangements may be possible according to theinvention, and that as the art continues to evolve new functionality andappropriate testing protocols may be implemented within the scope of theinvention.

According to another preferred embodiment of the invention, a method forautomated chat testing is disclosed. According to the embodiment, in aninitial step a test case is started. This may be performed as anautomated task, such as a scheduled event or part of a routine that isrun periodically or when certain conditions are met. It could alsooptionally be triggered by human interaction via a TCM platform, for thecreation and execution of custom test cases as might be desirable totest specific features or processes, or to perform a “trial run” of anew test case before it is set to run automatically. Upon execution of atest case, a plurality of virtual customers and agents are created,which are used as endpoints for the chat testing. This approachimplicitly tests each system involved in the chat process as the testruns. Results of the virtual customer and agent creation may be storedin a testing database or similar datastore, which may be located eitherlocally as a part of a contact center infrastructure, or may be any of avariety of remote storage media such as cloud-hosted storage locatedremotely from the contact center and accessed via the internet or otherdata network. Stored data may then be used later for generation ofdetailed reports for viewing test data, which may in turn also be storedfor later retrieval. Next, according to the specific test case beingperformed, one or more virtual customers initiate chat sessions. Such asession initiation request may be sent via the Internet or other datanetwork and handled similarly to an actual inbound request from acustomer. In order to enforce boundaries within the contact center andprevent a test case from impacting operations, a chat classifier may beimplemented to analyze chat requests passing through the center and“flag” them as test case-related as appropriate. In this manner, testdata may follow a similar path to actual customer interactions withoutinterfering with contact center operations such as sending a virtualcustomer's request to a real agent or exposing testing data tocustomers. It will be appreciated by one skilled in the art that thisstep may be optional, as it is not always necessary to run testing inparallel with normal center operations—for example, testing could be runoutside of a center's operating hours, when inbound traffic is handledby an automated system informing customers of the hours of operation andno traffic gets through to the center. Again, resultant data from thisstep may be logged in a data store for use in reporting. After a sessionis initiated and optionally classified, a virtual agent responds and thechat session proper may begin according to the test case being run (themethod described herein does not assume a particular script, it will beappreciated that such test cases may vary widely). Customer and agentexchange chat messages according to the test, results being loggedaccordingly, and optionally a CCM platform may interact with an agentdesktop to facilitate testing of the agent experience and test theoperation of contact center software. Such an agent desktop may be aphysical computer workstation running the agent desktop environmentsoftware, or it might be a virtual desktop being run inside of thetesting system without a physical computer presence. Results from agentdesktop interaction (if any) are logged, and finally all logged data iscollated into a results report upon completion of a test case. Resultantreports may be stored for later retrieval, and may be made viewable fromwithin a TCM platform for analysis by a user. In this manner, resultsfrom previous tests are available so that a user may optimize any futuretests from the TCM platform's graphical interface.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

The accompanying drawings illustrate several embodiments of theinvention and, together with the description, serve to explain theprinciples of the invention according to the embodiments. One skilled inthe art will recognize that the particular embodiments illustrated inthe drawings are merely exemplary, and are not intended to limit thescope of the present invention.

FIG. 1 is a block diagram illustrating an exemplary hardwarearchitecture of a computing device used in an embodiment of theinvention.

FIG. 2 is a block diagram illustrating an exemplary logical architecturefor a client device, according to an embodiment of the invention.

FIG. 3 is a block diagram showing an exemplary architectural arrangementof clients, servers, and external services, according to an embodimentof the invention.

FIG. 4 is a block diagram illustrating an exemplary system architecturefor automated chat testing integrated with traditional contact centercomponents, according to a preferred embodiment of the invention.

FIG. 5 is a block diagram illustrating a method for automated chattesting, according to a preferred embodiment of the invention.

FIG. 6 is an illustration of a test case creation interface, accordingto a preferred embodiment of the invention.

FIG. 7 is an illustration of a test results summary interface, accordingto a preferred embodiment of the invention.

DETAILED DESCRIPTION

The inventor has conceived, and reduced to practice, a system and methodfor automation of chat-based contact center interaction testing,comprising a flexible and scalable architecture and method to facilitatereliable automated testing and improve contact center operations.

One or more different inventions may be described in the presentapplication. Further, for one or more of the inventions describedherein, numerous alternative embodiments may be described; it should beunderstood that these are presented for illustrative purposes only. Thedescribed embodiments are not intended to be limiting in any sense. Oneor more of the inventions may be widely applicable to numerousembodiments, as is readily apparent from the disclosure. In general,embodiments are described in sufficient detail to enable those skilledin the art to practice one or more of the inventions, and it is to beunderstood that other embodiments may be utilized and that structural,logical, software, electrical and other changes may be made withoutdeparting from the scope of the particular inventions. Accordingly,those skilled in the art will recognize that one or more of theinventions may be practiced with various modifications and alterations.Particular features of one or more of the inventions may be describedwith reference to one or more particular embodiments or figures thatform a part of the present disclosure, and in which are shown, by way ofillustration, specific embodiments of one or more of the inventions. Itshould be understood, however, that such features are not limited tousage in the one or more particular embodiments or figures withreference to which they are described. The present disclosure is neithera literal description of all embodiments of one or more of theinventions nor a listing of features of one or more of the inventionsthat must be present in all embodiments.

Headings of sections provided in this patent application and the titleof this patent application are for convenience only, and are not to betaken as limiting the disclosure in any way.

Devices that are in communication with each other need not be incontinuous communication with each other, unless expressly specifiedotherwise. In addition, devices that are in communication with eachother may communicate directly or indirectly through one or moreintermediaries, logical or physical.

A description of an embodiment with several components in communicationwith each other does not imply that all such components are required. Tothe contrary, a variety of optional components may be described toillustrate a wide variety of possible embodiments of one or more of theinventions and in order to more fully illustrate one or more aspects ofthe inventions. Similarly, although process steps, method steps,algorithms or the like may be described in a sequential order, suchprocesses, methods and algorithms may generally be configured to work inalternate orders, unless specifically stated to the contrary. In otherwords, any sequence or order of steps that may be described in thispatent application does not, in and of itself, indicate a requirementthat the steps be performed in that order. The steps of describedprocesses may be performed in any order practical. Further, some stepsmay be performed simultaneously despite being described or implied asoccurring non-simultaneously (e.g., because one step is described afterthe other step). Moreover, the illustration of a process by itsdepiction in a drawing does not imply that the illustrated process isexclusive of other variations and modifications thereto, does not implythat the illustrated process or any of its steps are necessary to one ormore of the invention(s), and does not imply that the illustratedprocess is preferred. Also, steps are generally described once perembodiment, but this does not mean they must occur once, or that theymay only occur once each time a process, method, or algorithm is carriedout or executed. Some steps may be omitted in some embodiments or someoccurrences, or some steps may be executed more than once in a givenembodiment or occurrence.

When a single device or article is described, it will be readilyapparent that more than one device or article may be used in place of asingle device or article. Similarly, where more than one device orarticle is described, it will be readily apparent that a single deviceor article may be used in place of the more than one device or article.

The functionality or the features of a device may be alternativelyembodied by one or more other devices that are not explicitly describedas having such functionality or features. Thus, other embodiments of oneor more of the inventions need not include the device itself.

Techniques and mechanisms described or referenced herein will sometimesbe described in singular form for clarity. However, it should be notedthat particular embodiments include multiple iterations of a techniqueor multiple instantiations of a mechanism unless noted otherwise.Process descriptions or blocks in figures should be understood asrepresenting modules, segments, or portions of code which include one ormore executable instructions for implementing specific logical functionsor steps in the process. Alternate implementations are included withinthe scope of embodiments of the present invention in which, for example,functions may be executed out of order from that shown or discussed,including substantially concurrently or in reverse order, depending onthe functionality involved, as would be understood by those havingordinary skill in the art.

DEFINITIONS

A “chat cruncher”, as used herein, is a software or hardware-basedsystem that is designed to receive input of test case information andproduce chat-based output for the execution of a test case. In thismanner a chat cruncher may be used to simulate chat-based interactionsby producing predetermined chat messages to initiate interactions or inresponse to received input during an interaction, replicating the effectof interacting with another individual user via a chat-basedcommunication system.

A “chat classifier”, as used herein, is a software or hardware-basedsystem that is designed to receive a flow of chat-based interaction dataand analyze it to determine whether it is part of a test case or anactual customer interaction. The chat classifier may then determine howchat data is to be routed, such as sending interaction chat data tocontact center agents for handling while sending test case data to othertesting systems. In this manner, a chat classifier may be responsiblefor boundary enforcement, preventing any test data from overlapping orinterfering with actual contact center operations.

A “desktop automation engine”, abbreviated DAE, as used herein, is asoftware-based system design to emulate contact center agent interactionwith agent desktop software elements for testing of such elements, whichmay be run normally as in an agent's desktop environment during contactcenter operations. In this manner, a desktop automation engine may beconfigured on an existing agent desktop to interact with standardelements of the desktop environment, rather than requiring a dedicatedor specialized desktop to be configured specifically for testingpurposes.

Hardware Architecture

Generally, the techniques disclosed herein may be implemented onhardware or a combination of software and hardware. For example, theymay be implemented in an operating system kernel, in a separate userprocess, in a library package bound into network applications, on aspecially constructed machine, on an application-specific integratedcircuit (ASIC), or on a network interface card.

Software/hardware hybrid implementations of at least some of theembodiments disclosed herein may be implemented on a programmablenetwork-resident machine (which should be understood to includeintermittently connected network-aware machines) selectively activatedor reconfigured by a computer program stored in memory. Such networkdevices may have multiple network interfaces that may be configured ordesigned to utilize different types of network communication protocols.A general architecture for some of these machines may be disclosedherein in order to illustrate one or more exemplary means by which agiven unit of functionality may be implemented. According to specificembodiments, at least some of the features or functionalities of thevarious embodiments disclosed herein may be implemented on one or moregeneral-purpose computers associated with one or more networks, such asfor example an end-user computer system, a client computer, a networkserver or other server system, a mobile computing device (e.g., tabletcomputing device, mobile phone, smartphone, laptop, and the like), aconsumer electronic device, a music player, or any other suitableelectronic device, router, switch, or the like, or any combinationthereof. In at least some embodiments, at least some of the features orfunctionalities of the various embodiments disclosed herein may beimplemented in one or more virtualized computing environments (e.g.,network computing clouds, virtual machines hosted on one or morephysical computing machines, or the like).

Referring now to FIG. 1, there is shown a block diagram depicting anexemplary computing device 100 suitable for implementing at least aportion of the features or functionalities disclosed herein. Computingdevice 100 may be, for example, any one of the computing machines listedin the previous paragraph, or indeed any other electronic device capableof executing software- or hardware-based instructions according to oneor more programs stored in memory. Computing device 100 may be adaptedto communicate with a plurality of other computing devices, such asclients or servers, over communications networks such as a wide areanetwork a metropolitan area network, a local area network, a wirelessnetwork, the Internet, or any other network, using known protocols forsuch communication, whether wireless or wired.

In one embodiment, computing device 100 includes one or more centralprocessing units (CPU) 102, one or more interfaces 110, and one or morebusses 106 (such as a peripheral component interconnect (PCI) bus). Whenacting under the control of appropriate software or firmware, CPU 102may be responsible for implementing specific functions associated withthe functions of a specifically configured computing device or machine.For example, in at least one embodiment, a computing device 100 may beconfigured or designed to function as a server system utilizing CPU 102,local memory 101 and/or remote memory 120, and interface(s) 110. In atleast one embodiment, CPU 102 may be caused to perform one or more ofthe different types of functions and/or operations under the control ofsoftware modules or components, which for example, may include anoperating system and any appropriate applications software, drivers, andthe like.

CPU 102 may include one or more processors 103 such as, for example, aprocessor from one of the Intel, ARM, Qualcomm, and AMD families ofmicroprocessors. In some embodiments, processors 103 may includespecially designed hardware such as application-specific integratedcircuits (ASICs), electrically erasable programmable read-only memories(EEPROMs), field-programmable gate arrays (FPGAs), and so forth, forcontrolling operations of computing device 100. In a specificembodiment, a local memory 101 (such as non-volatile random accessmemory (RAM) and/or read-only memory (ROM), including for example one ormore levels of cached memory) may also form part of CPU 102. However,there are many different ways in which memory may be coupled to system100. Memory 101 may be used for a variety of purposes such as, forexample, caching and/or storing data, programming instructions, and thelike.

As used herein, the term “processor” is not limited merely to thoseintegrated circuits referred to in the art as a processor, a mobileprocessor, or a microprocessor, but broadly refers to a microcontroller,a microcomputer, a programmable logic controller, anapplication-specific integrated circuit, and any other programmablecircuit.

In one embodiment, interfaces 110 are provided as network interfacecards (NICs). Generally, NICs control the sending and receiving of datapackets over a computer network; other types of interfaces 110 may forexample support other peripherals used with computing device 100. Amongthe interfaces that may be provided are Ethernet interfaces, frame relayinterfaces, cable interfaces, DSL interfaces, token ring interfaces,graphics interfaces, and the like. In addition, various types ofinterfaces may be provided such as, for example, universal serial bus(USB), Serial, Ethernet, FIREWIRE™, PCI, parallel, radio frequency (RF),BLUETOOTH™, near-field communications (e.g., using near-fieldmagnetics), 802.11 (WiFi), frame relay, TCP/IP, ISDN, fast Ethernetinterfaces, Gigabit Ethernet interfaces, asynchronous transfer mode(ATM) interfaces, high-speed serial interface (HSSI) interfaces, Pointof Sale (POS) interfaces, fiber data distributed interfaces (FDDIs), andthe like. Generally, such interfaces 110 may include ports appropriatefor communication with appropriate media. In some cases, they may alsoinclude an independent processor and, in some in stances, volatileand/or non-volatile memory (e.g., RAM).

Although the system shown in FIG. 1 illustrates one specificarchitecture for a computing device 100 for implementing one or more ofthe inventions described herein, it is by no means the only devicearchitecture on which at least a portion of the features and techniquesdescribed herein may be implemented. For example, architectures havingone or any number of processors 103 may be used, and such processors 103may be present in a single device or distributed among any number ofdevices. In one embodiment, a single processor 103 handlescommunications as well as routing computations, while in otherembodiments a separate dedicated communications processor may beprovided. In various embodiments, different types of features orfunctionalities may be implemented in a system according to theinvention that includes a client device (such as a tablet device orsmartphone running client software) and server systems (such as a serversystem described in more detail below).

Regardless of network device configuration, the system of the presentinvention may employ one or more memories or memory modules (such as,for example, remote memory block 120 and local memory 101) configured tostore data, program instructions for the general-purpose networkoperations, or other information relating to the functionality of theembodiments described herein (or any combinations of the above). Programinstructions may control execution of or comprise an operating systemand/or one or more applications, for example. Memory 120 or memories101, 120 may also be configured to store data structures, configurationdata, encryption data, historical system operations information, or anyother specific or generic non-program information described herein.

Because such information and program instructions may be employed toimplement one or more systems or methods described herein, at least somenetwork device embodiments may include nontransitory machine-readablestorage media, which, for example, may be configured or designed tostore program instructions, state information, and the like forperforming various operations described herein. Examples of suchnontransitory machine-readable storage media include, but are notlimited to, magnetic media such as hard disks, floppy disks, andmagnetic tape; optical media such as CD-ROM disks; magneto-optical mediasuch as optical disks, and hardware devices that are speciallyconfigured to store and perform program instructions, such as read-onlymemory devices (ROM), flash memory, solid state drives, memristormemory, random access memory (RAM), and the like. Examples of programinstructions include both object code, such as may be produced by acompiler, machine code, such as may be produced by an assembler or alinker, byte code, such as may be generated by for example a JAVA™compiler and may be executed using a Java virtual machine or equivalent,or files containing higher level code that may be executed by thecomputer using an interpreter (for example, scripts written in Python,Perl, Ruby, Groovy, or any other scripting language).

In some embodiments, systems according to the present invention may beimplemented on a standalone computing system. Referring now to FIG. 2,there is shown a block diagram depicting a typical exemplaryarchitecture of one or more embodiments or components thereof on astandalone computing system. Computing device 200 includes processors210 that may run software that carry out one or more functions orapplications of embodiments of the invention, such as for example aclient application 230. Processors 210 may carry out computinginstructions under control of an operating system 220 such as, forexample, a version of Microsoft's WINDOWS™ operating system, Apple's MacOS/X or iOS operating systems, some variety of the Linux operatingsystem, Google's ANDROID™ operating system, or the like. In many cases,one or more shared services 225 may be operable in system 200, and maybe useful for providing common services to client applications 230.Services 225 may for example be WINDOWS™ services, user-space commonservices in a Linux environment, or any other type of common servicearchitecture used with operating system 210. Input devices 270 may be ofany type suitable for receiving user input, including for example akeyboard, touchscreen, microphone (for example, for voice input), mouse,touchpad, trackball, or any combination thereof. Output devices 260 maybe of any type suitable for providing output to one or more users,whether remote or local to system 200, and may include for example oneor more screens for visual output, speakers, printers, or anycombination thereof. Memory 240 may be random-access memory having anystructure and architecture known in the art, for use by processors 210,for example to run software. Storage devices 250 may be any magnetic,optical, mechanical, memristor, or electrical storage device for storageof data in digital form. Examples of storage devices 250 include flashmemory, magnetic hard drive, CD-ROM, and/or the like.

In some embodiments, systems of the present invention may be implementedon a distributed computing network, such as one having any number ofclients and/or servers. Referring now to FIG. 3, there is shown a blockdiagram depicting an exemplary architecture for implementing at least aportion of a system according to an embodiment of the invention on adistributed computing network. According to the embodiment, any numberof clients 330 may be provided. Each client 330 may run software forimplementing client-side portions of the present invention; clients maycomprise a system 200 such as that illustrated in FIG. 2. In addition,any number of servers 320 may be provided for handling requests receivedfrom one or more clients 330. Clients 330 and servers 320 maycommunicate with one another via one or more electronic networks 310,which may be in various embodiments any of the Internet, a wide areanetwork, a mobile telephony network, a wireless network (such as WiFi,Wimax, and so forth), or a local area network (or indeed any networktopology known in the art; the invention does not prefer any one networktopology over any other). Networks 310 may be implemented using anyknown network protocols, including for example wired and/or wirelessprotocols.

In addition, in some embodiments, servers 320 may call external services370 when needed to obtain additional information, or to refer toadditional data concerning a particular call. Communications withexternal services 370 may take place, for example, via one or morenetworks 310. In various embodiments, external services 370 may compriseweb-enabled services or functionality related to or installed on thehardware device itself. For example, in an embodiment where clientapplications 230 are implemented on a smartphone or other electronicdevice, client applications 230 may obtain information stored in aserver system 320 in the cloud or on an external service 370 deployed onone or more of a particular enterprise's or user's premises.

In some embodiments of the invention, clients 330 or servers 320 (orboth) may make use of one or more specialized services or appliancesthat may be deployed locally or remotely across one or more networks310. For example, one or more databases 340 may be used or referred toby one or more embodiments of the invention. It should be understood byone having ordinary skill in the art that databases 340 may be arrangedin a wide variety of architectures and using a wide variety of dataaccess and manipulation means. For example, in various embodiments oneor more databases 340 may comprise a relational database system using astructured query language (SQL), while others may comprise analternative data storage technology such as those referred to in the artas “NoSQL” (for example, Hadoop Cassandra, Google BigTable, and soforth). In some embodiments, variant database architectures such ascolumn-oriented databases, in-memory databases, clustered databases,distributed databases, or even flat file data repositories may be usedaccording to the invention. It will be appreciated by one havingordinary skill in the art that any combination of known or futuredatabase technologies may be used as appropriate, unless a specificdatabase technology or a specific arrangement of components is specifiedfor a particular embodiment herein. Moreover, it should be appreciatedthat the term “database” as used herein may refer to a physical databasemachine, a cluster of machines acting as a single database system, or alogical database within an overall database management system. Unless aspecific meaning is specified for a given use of the term “database”, itshould be construed to mean any of these senses of the word, all ofwhich are understood as a plain meaning of the term “database” by thosehaving ordinary skill in the art.

Similarly, most embodiments of the invention may make use of one or moresecurity systems 360 and configuration systems 350. Security andconfiguration management are common information technology (IT) and webfunctions, and some amount of each are generally associated with any ITor web systems. It should be understood by one having ordinary skill inthe art that any configuration or security subsystems known in the artnow or in the future may be used in conjunction with embodiments of theinvention without limitation, unless a specific security 360 orconfiguration system 350 or approach is specifically required by thedescription of any specific embodiment.

In various embodiments, functionality for implementing systems ormethods of the present invention may be distributed among any number ofclient and/or server components. For example, various software modulesmay be implemented for performing various functions in connection withthe present invention, and such modules may be variously implemented torun on server and/or client components.

Conceptual Architecture

FIG. 4 is a block diagram of a preferred embodiment of the invention,illustrating a system for automated chat testing incorporating commoncontact center elements and running in parallel to actual contact centeroperations. As illustrated, a contact center 400 may implement a TCMplatform 401, which may serve as the beginning or origin of a test case.TCM platform 401 may operate automatically or optionally may accepthuman interaction via a graphical user interface for manipulation oftest cases and viewing of test result reports which may be stored in atesting database 402. When a test is run, TCM platform 401 initiates atest case with chat cruncher 403 and CCM platform 410, which may eachthen begin their respective automated testing processes. Chat cruncher403 may simulate a plurality of virtual customers 405 which operate viaa web server 404 to send and receive data via an internet or other datacommunications network 406, while CCM platform 410 may similarlysimulate virtual contact center agents 411 which may receive and respondto data requests. Data requests sent by simulated customers 405 via adata network 406 may be received and handled by a router 407, which mayforward requests from customers to an interaction server 408 andrequests from agents to customers via a data network 407. Interactionserver 408 may verify data requests with a chat classifier 409, whichmay identify requests as part of a test case or actual contact centeroperations, to determine handling protocol. If a request is determinedto be a part of a test case, interaction server 408 may then proceedwith test case handling. If a request is inbound from router 407, it maybe forwarded to CCM platform 410 for handling by virtual agents 411, orif it is an outbound request from a virtual agent 411 it may be sent torouter 407 for transmission to a virtual customer 405 via a data network406. Virtual agents 411 may operate by interacting directly withinteraction server 408 or by automatically interacting with a real orsimulated agent desktop environment according to the specific nature ofa test case. During and/or after the execution of a test case, data maybe stored in a database 402 by CCM platform 410 or chat cruncher 403,for the formulation of test reports to be stored for later viewing by auser via TCM platform 401. In this manner it will be appreciated thatthe flow of data requests within a test case is bidirectional, i.e.requests may continually and asynchronously be sent from simulatedcustomers 405 to simulated agents 411 and vice-versa, withoutnecessitating a strict pattern or rhythm of data flow. It will beappreciated that in such a manner it is possible to simulate a customersending multiple chat requests while an agent waits to send a response,or for an agent to send multiple requests while a customer waits. Suchoccurrences are commonplace in practice, and in this manner a test casemay more accurately simulate actual contact center operations for morerelevant and reliable testing data.

As illustrated according to the embodiment, normal operations maycontinue uninterrupted within a contact center 400 while a test case isbeing performed. Customers 420 may continue to operate a chat interface421 as normal without any impact on customer experience from a testcase, sending chat requests to contact center agents 422 according tothe flow illustrated. Chat requests may be sent from a chat interface421 via a data network 406, requests may then be received and handled bya router 407 within a contact center. Router 407 may then send requeststo an interaction server 408, which may then verify requests with a chatclassifier 409 to determine their nature as legitimate customerinteraction. Requests may then be sent to agents 421, and returnrequests follow an opposite path through interaction server 408, router407, and then outward from contact center 400 via a data network 406 toa customer's chat interface 421. In this manner it will be appreciatedthat normal contact center operations may be running in parallel to testcases, without any impact on customer experience.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

FIG. 5 is a method illustration of a preferred embodiment of theinvention, illustrating a general flow for handling automated chattesting within a contact center. In an initial step 501, a test casebegins. Such a test case may be triggered automatically as a scheduledevent or part of a routine, or it may be triggered manually via userinteraction with a TCM platform 401 as described previously. In a secondstep 502, virtual agents and virtual customers are created within thetesting system and the results of their creation may be logged into atesting database 402 or other storage medium during a logging step 507.A virtual customer then initiates a chat session in a step 503, and theresults may again be logged in a logging step 507. A chat classifierthen classifies this chat session as part of a test case in a step 503,to ensure boundary enforcement so that test data does not overlap orotherwise interfere with production environment data during contactcenter operation. Upon receipt of a test chat request, a virtual agentmay then respond in a step 504, and the results of this response arelogged in a logging step 505. According to the test case, a CCM platform410 may interact with a real or virtual agent desktop to test agentexperience and further evaluate contact center operation in a step 506,and the results of this interaction may be logged in a logging step 507.Finally, logged information from previous steps of a test case may beaggregated and formulated into a results report in a reporting step 508,which may be further stored in a database 402 or similar storage mediumfor later retrieval. It will be appreciated that such a method flow isexemplary, and that while the illustrated flow is thought to be an idealsolution by the inventor, alternate implementations are possibleaccording to the invention. It will be further appreciated thatalternate or additional components may be incorporated into a test case,and that the illustrated flow should not be construed as limiting thescope of the testing process to merely the elements described, as a keyfeature of the invention is scalability and as such it can be readilyadapted to a wide variety of contact center architectures, implementedas additional steps inserted into a testing process as illustrated.

FIG. 6 is an illustration of an exemplary graphical user interface 600for user creation and modification of a test case within a TCM platform,according to a preferred embodiment of the invention. As illustrated, aninterface 600 may comprise several components such as an interactivebutton or similar element for creation of a new test step 601, aplurality of text fields describing elements of existing test steps suchas a step description 602, text strings to wait for 603, text to send604, criteria for pause length between steps 605, clickable or otherwiseinteractive elements for deleting steps 606 or selecting steps toperform batch operations 609, clickable or otherwise interactiveelements for reordering steps 607, clickable or otherwise interactiveelements for editing existing steps 608, or clickable or otherwiseinteractive elements for manipulating selected steps 610 such as (asillustrated) deleting multiple steps in a single operation.

When a step is created, a user may supply a variety of information toidentify and control behavior of the test step. For example, asillustrated, a description field 602 may be implemented to identifysteps for ease of interpreting previously-created test cases.Behavior-controlling fields as illustrated may include text strings thata test agent or customer must wait to receive before proceeding 603, orsimilar text strings that should be sent when a step is initiated 604.In this manner, each step may simulate a “send-receive” pattern tosimulate customer-agent interaction, or a step might include only one ofthe two fields so as to simulate asymmetrical interaction wherein oneparty might send multiple chat messages before receiving a response. Asfurther illustrated, numerical behavior-controlling elements may beimplemented such as to specify wait times between steps 605, controllingthe pace of a test case. This might be implemented to facilitate“stress-testing” of a contact center under heavy traffic, or to pacetests to distribute the system load so as to avoid load-based failurewhile testing other features or systems (i.e., when stress-testing isnot a goal of the test case).

FIG. 7 is an illustration of an exemplary graphical user interface 700for viewing of a testing results report, according to a preferredembodiment of the invention. As illustrated, an interface 700 maycomprise a variety of elements intended to convey information containedin stored logs from previously-run or currently-running test cases asdescribed previously, such elements optionally including clickable orotherwise interactive buttons 701 and 707, text display fields 702, textinput fields 706, graphical or text-based tables or charts 703, 704, and705, or any of a variety of other user interface elements as arecommonly found in the art. Such elements as illustrated are exemplary,and it will be appreciated that a variety of arrangements utilizingalternate, additional, or fewer elements may be possible according tothe invention, however the illustrated arrangement is preferred by theinventor as an effective method of displaying desirable content to auser.

As illustrated, a clickable or otherwise user interactive element suchas a button or drop-down list-style menu 701 may display and allow auser to select a results report for viewing, selecting from a variety ofreports available in a storage medium such as database 402. A user mayselect a report from such an element, which may then dynamically updatedisplayed content of interface 700 to reflect the relevant data from theselected report. Text display fields 702 may be implemented to presentnon-interactive data to a user, i.e. recorded information about aprevious test case that a user should not have a need or ability tomanipulate, as may be desirable to prevent inconsistent or unreliabledata due to human tampering or error. Such presented information mayinclude (but is not limited to) a test case or test campaign name,numerical counts of the quantity of chat sessions or requests performedduring a test case, and timestamp data such as dates and times thattests were run or chats were initiated. It will be appreciated that suchinformation may be highly variable according to the specific nature of atest case and according to a particular implementation of the inventionwithin a contact center, and that such information as illustrated isexemplary and alternate, substitute, or additional information may bedisplayed according to the invention.

An interface 700 may also comprise (as illustrated) a number ofgraphical or text-based tables or charts 703, 704, and 705 forpresentation of formulated or otherwise organized data to a user. Agraphical chart 703 such as a circular graph representing relativepercentages of passed or failed tests, or other statistics which mightbe suitable for graphical presentation such as durations or quantitiesinvolved. Such a graph might be clickable or otherwise user-interactive,such interactivity optionally allowing a user to tailor the informationbeing represented within a graph and optionally dynamically updating thedisplay when a selection is made. In this manner, a user may viewmultiple statistics for a given report concisely, without the need toclutter interface 700 with a large number of graphs, and a user may beable to view only that data which is of interest without having tonavigate through irrelevant or undesirable information, thereby reducingthe time and frustration for a user as well as increasing reliability ofanalysis by reducing the risk of misinterpreted data. A text-based tableor chart 704 may be implemented to present such data as detailedinformation on individual interactions within a test case, such as (asillustrated) the names or types of chat interactions initiated as partof a test, quantities of interactions or other numerical measurements,and proportions of success and failure among displayed interactions. Itwill be appreciated that such information as illustrated is exemplary,and additional or alternate information might be presented according toa specific report or implementation within a contact center, inaccordance with the invention.

A text-based table or chart 705 may be displayed presenting detailedinformation logged form interactions within a test case. Suchinformation might include (but is not limited to) interaction number andname, location in which an interaction's logged information is stored,time or duration of an interaction, result of an interaction's executionwith optionally variable detail level (such as a simple pass/fail or adetailed error report), or clickable or otherwise user-interactiveelements such as hyperlinks or buttons, as might be used (asillustrated) to display a visual log of an interaction when clicked. Itwill be appreciated that such information is exemplary, and may varywidely according to a specific report or implementation within a contactcenter, and furthermore that such information might be customizable by auser so as to only view data of interest as described previously, byselecting what data to display in any particular field, row, or columnof a chart or table. Accordingly, clickable or otherwiseuser-interactive elements may be utilized to control the displayed datain a chart or table, such as a text entry field 706 where a user mightenter a specific interaction name or number to view in more detail, or aclickable drop-down list-style field 707 which might enable a user topick from a selection of data optionally sorted or presented in anorderly fashion for efficient navigation. It will be appreciated thatsuch elements are exemplary and that the nature and function of allillustrated elements may vary according to the invention, and that newmethods and arrangements of user interface elements may become availablewithin the art and be utilized according to the invention.

The skilled person will be aware of a range of possible modifications ofthe various embodiments described above. Accordingly, the presentinvention is defined by the claims and their equivalents.

What is claimed is:
 1. A system for automated testing of a chat-basedinteraction environment, comprising: a text chat cruncher computercomprising a memory, a processor, a network interface, and a pluralityof programmable instructions stored in the memory and operable on theprocessor, the programmable instructions configured to execute text chattest cases; a contact center manager computer attached to a network andcomprising programmable instructions stored and operable thereon tomanage contact center interactions; and a text chat classifier computerattached to the network and comprising programmable instructions storedand operable thereon to analyze live customer text chat requests and totest text chat requests; wherein the text chat cruncher computeroperates a plurality of virtual customers as independent software agentsunder control of the programmable instructions for executing text chattest cases; wherein the contact center manager computer operates aplurality of virtual agents to participate in text chat session with thevirtual customers; wherein the text chat classifier computer classifiesinteractions according to their nature as either live customer text chatinteractions or test text chat interactions to enforce boundariesbetween a running test and an operating contact center environment. 2.The system of claim 1, further comprising a desktop automation computercomprising programmable instructions stored and operable thereon;wherein the desktop automation computer operates a real or simulatedagent desktop for testing of agent experience and softwarefunctionality.